Dubbo 实现高速序列化

Dubbo 实现高速序列化

Dubbo 中的序列化

Dubbo RPC 是 Dubbo 体系中最核心的一种高性能、高吞吐量的远程调用方式,可以称之为多路复用的 TCP 长连接调用:

  • 长连接: 避免了每次调用新建 TCP 连接,提高了调用的响应速度
  • 多路复用: 单个 TCP 连接可交替传输多个请求和响应的消息,降低了连接的等待闲置时间,从而减少了同样并发数下的网络连接数,提高了系统吞吐量

Dubbo RPC 主要用于两个 Dubbo 系统之间的远程调用,特别适合高并发、小数据的互联网场景。而序列化对于远程调用的响应速度、吞吐量、网络带宽消耗等同样也起着至关重要的作用,是我们提升分布式系统性能的最关键因素之一。

Dubbo 中支持的序列化方式:

  • dubbo 序列化: 阿里尚未开发成熟的高效 Java 序列化实现,阿里不建议在生产环境使用它
  • hessian2 序列化: hessian 是一种跨语言的高效二进制序列化方式。但这里实际不是原生的 hessian2 序列化,而是阿里修改过的 hessian lite,它是 dubbo RPC 默认启用的序列化方式
  • json 序列化: 目前有两种实现,一种是采用的阿里的 fastjson 库,另一种是采用 dubbo 中自己实现的简单 json 库,但其实现都不是特别成熟,而且 json 这种文本序列化性能一般不如上面两种二进制序列化。
  • java 序列化: 主要是采用 JDK 自带的 Java 序列化实现,性能很不理想。

在通常情况下,这四种主要序列化方式的性能从上到下依次递减。对于 dubbo RPC 这种追求高性能的远程调用方式来说,实际上只有 1、2 两种高效序列化方式比较般配,而第 1 个 dubbo 序列化由于还不成熟,所以实际只剩下 2 可用,所以 dubbo RPC 默认采用 hessian2 序列化。

但 hessian 是一个比较老的序列化实现了,而且它是跨语言的,所以不是单独针对 Java 进行优化的。而 dubbo RPC 实际上完全是一种 Java to Java 的远程调用,其实没有必要采用跨语言的序列化方式(当然肯定也不排斥跨语言的序列化)。

最近几年,各种新的高效序列化方式层出不穷,不断刷新序列化性能的上限,最典型的包括:

  • 专门针对 Java 语言的:Kryo,FST 等等
  • 跨语言的:Protostuff,ProtoBuf,Thrift,Avro,MsgPack 等等

这些序列化方式的性能多数都显著优于 hessian2(甚至包括尚未成熟的 dubbo 序列化),有鉴于此,我们为 dubbo 引入 Kryo 和 FST 这两种高效 Java 序列化实现,来逐步取代 hessian2。

其中,Kryo 是一种非常成熟的序列化实现,已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目(如 Hive、Storm)中广泛的使用。而 FST 是一种较新的序列化实现,目前还缺乏足够多的成熟使用案例。

注意: 在面向生产环境的应用中,目前更优先选择 Kryo

启用 Kryo

在 Provider 和 Consumer 项目启用 Kryo 高速序列化功能,两个项目的配置方式相同

POM

增加 org.apache.dubbo:dubbo-serialization-kryo 依赖

<properties>
    <dubbo-kryo.version>2.7.2</dubbo-kryo.version>
</properties>

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-serialization-kryo</artifactId>
    <version>${dubbo-kryo.version}</version>
</dependency>

application.yml

增加 dubbo.protocol.serialization=kryo 配置

dubbo:
  protocol:
    serialization: kryo

序列化类说明

注意: 想要使用 Kryo 序列化只需要 DTO/Domain/Entity 这类传输对象实现序列化接口即可,无需额外再做配置,如:public class User implements Serializable{}

在对一个类做序列化的时候,可能还级联引用到很多类,比如 Java 集合类。针对这种情况,Dubbo 已经自动将 JDK 中的常用类进行了注册,包括:

GregorianCalendar
InvocationHandler
BigDecimal
BigInteger
Pattern
BitSet
URI
UUID
HashMap
ArrayList
LinkedList
HashSet
TreeSet
Hashtable
Date
Calendar
ConcurrentHashMap
SimpleDateFormat
Vector
BitSet
StringBuffer
StringBuilder
Object
Object[]
String[]
byte[]
char[]
int[]
float[]
double[]

由于注册被序列化的类仅仅是出于性能优化的目的,所以即使你忘记注册某些类也没有关系。事实上,即使不注册任何类,Kryo 和 FST 的性能依然普遍优于 hessian 和 dubbo 序列化。

附:扩展阅读

序列化性能分析与测试

测试环境

  • 两台独立服务器
  • 4 核 Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz
  • 8G 内存
  • 虚拟机之间网络通过百兆交换机
  • CentOS 5
  • JDK 7
  • Tomcat 7
  • JVM 参数 -server -Xms1g -Xmx1g -XX:PermSize=64M -XX:+UseConcMarkSweepGC

注意: 当然这个测试环境较有局限,故当前测试结果未必有非常权威的代表性

测试脚本

和 dubbo 自身的基准测试保持接近,10 个并发客户端持续不断发出请求:

  • 传入嵌套复杂对象(但单个数据量很小),不做任何处理,原样返回
  • 传入 50K 字符串,不做任何处理,原样返回(TODO:结果尚未列出)

进行 5 分钟性能测试。(引用 dubbo 自身测试的考虑:“主要考察序列化和网络 IO 的性能,因此服务端无任何业务逻辑。取 10 并发是考虑到 HTTP 协议在高并发下对 CPU 的使用率较高可能会先达到瓶颈。”)

Dubbo RPC 中不同序列化生成字节大小比较

序列化生成字节码的大小是一个比较有确定性的指标,它决定了远程调用的网络传输时间和带宽占用。针对复杂对象的结果如下(数值越小越好):

Dubbo RPC 中不同序列化响应时间和吞吐量对比

结论

就目前结果而言,我们可以看到不管从生成字节的大小,还是平均响应时间和平均 TPS,Kryo 和 FST 相比 Dubbo RPC 中原有的序列化方式都有非常显著的改进。


赏一赏
 上一篇
Dubbo 负载均衡 Dubbo 负载均衡
Dubbo 负载均衡概述在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。 负载均衡策略随机Random LoadBalance: 按权重设置随机概率,在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按
2019-11-25
下一篇 
Sentinel 客户端接入 Sentinel 客户端接入
Sentinel 客户端接入POM如果要在您的项目中引入 Sentinel,需要增加 org.springframework.cloud:spring-cloud-starter-alibaba-sentinel Starter POM &